home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000167_owner-urn-ietf _Thu Nov 14 14:08:13 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA26494 for urn-ietf-out; Thu, 14 Nov 1996 14:08:13 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA26489 for <urn-ietf@services.bunyip.com>; Thu, 14 Nov 1996 14:08:09 -0500
  3. Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA21875  (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 14:07:36 -0500
  5. Received: by seawall with  (8.6.12/) id OAA14295; Thu, 14 Nov 1996 14:07:00 -0500
  6. Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3)
  7.     id sma014285; Thu Nov 14 14:06:58 1996
  8. Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail
  9.     id <328B6DF5@MSMAIL.INDY.TCE.COM>; Thu, 14 Nov 96 14:07:33 EST
  10. From: Fisher Mark <FisherM@is3.indy.tce.com>
  11. To: "dgd@cs.bu.edu" <dgd@cs.bu.edu>, Martin J Duerst <mduerst@ifi.unizh.ch>,
  12.         "moore@cs.utk.edu" <moore@cs.utk.edu>
  13. Cc: "stu_weibel@oclc.org" <stu_weibel@oclc.org>,
  14.         "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  15. Subject: Re: [URN] Re: I18N does not belong in URNs
  16. Date: Thu, 14 Nov 96 14:05:00 EST
  17. Message-Id: <328B6DF5@MSMAIL.INDY.TCE.COM>
  18. Encoding: 48 TEXT
  19. X-Mailer: Microsoft Mail V3.0
  20. Sender: owner-urn-ietf@services.bunyip.com
  21. Precedence: bulk
  22. Reply-To: Fisher Mark <FisherM@is3.indy.tce.com>
  23. Errors-To: owner-urn-ietf@bunyip.com
  24.  
  25. Martin J Duerst writes:
  26. >I have stopped proposing adding i18n support for meaningfulness.
  27. >This argument is not necessary. But I think it is necessary that
  28. >the same amount of meaningfulness is allowed or disallowed to
  29. >users of any language around the globe. This is only guaranteed
  30. >by either radically restricting the character set or completely
  31. >opening it up.
  32.  
  33. I would further propose that if "meaninglessness" is a requirement, only 
  34. random identifiers will do.  If there is a meaning present, people will use 
  35. it.  I do not, however, think that URNs must necessarily have no meaning to 
  36. humans -- they may, or they may not.  It is up to namespace designer.  (And 
  37. there may be a _lot_ of those!)
  38.  
  39. Meanwhile, David Durand writes:
  40. >At 5:17 PM 11/13/96, Keith Moore wrote:
  41. >>was imprecise and possibly misleading.  A better statement is:
  42. >>
  43. >>   "URNs aren't intended to serve as human meaningful names".
  44. >>
  45. >>Keith
  46. >
  47. >This means the human meaningfulness is not a requirement of URNs. This is
  48. >probably good. But it is _not_ as you have claimed, a requirement that URNs
  49. >_not_ be human-readable.
  50. >
  51. >    As I have repeatedly pointed out, compatibility with existing
  52. >persistent namespaces will require that at least some human-meaningful
  53. >names be included. The notion of requiring users of FPIs (for instance) to
  54. >hex-encode 50+ character ascii strings stil strikes me a ludicrous. But
  55. >once we allow ASCII, we have to meet the questions of the international
  56. >community. My feeling is that transcribability is a more serious problem
  57. >than the UTF-8 advocates are admitting. On the other hand, if the reference
  58. >string is the %-encoded UTF-8 value, then we should be OK for
  59. >transcribability. The issue of user-friendly software that hides %-encoding
  60. >is not part of the protocol, so its _possibility_ shouldn't unduly
  61. >influence us.
  62.  
  63. Although UTF-8 is not perfect, it is by far the closest system now existing 
  64. that represents most characters in use today.  If we are to permit but not 
  65. require that URNs have human meanings, and we are not going to force 
  66. grandfathered namespaces to translate their IDs, then UTF-8 is likely the 
  67. best choice for a character encoding scheme, with the reference string as 
  68. the %-encoded UTF-8 value.
  69. ======================================================================
  70. Mark Leighton Fisher                   Thomson Consumer Electronics
  71. fisherm@indy.tce.com                   Indianapolis, IN